Mention that servers may use ERR_NOSUCHCHANNEL instead of ERR_CHANOPRIVSNEEDED to conceal +s channels #247
Conversation
…IVSNEEDED to conceal +s channels This matches InspIRCd's behavior, which Ergo is considering too. As far as I can tell, no one else implements it this way, so this is not phrased as a requirement.
_includes/modern-appendix.md
Outdated
| @@ -149,6 +149,9 @@ This channel mode controls whether the channel is 'secret', and does not have an | |||
|
|
|||
| A channel that is set to secret will not show up in responses to the {% message LIST %} or {% message NAMES %} command unless the client sending the command is joined to the channel. Likewise, secret channels will not show up in the {% numeric RPL_WHOISCHANNELS %} numeric unless the user the numeric is being sent to is joined to that channel. | |||
|
|
|||
| Additionally, servers may return {% numeric ERR_NOSUCHCHANNEL %} instead of {% numeric ERR_CHANOPRIVSNEEDED %} to channel commands ({% message MODE %}, {% message TOPIC %}, {% message PRIVMSG %}, {% message NOTICE %}) to a secret channel from a user not on that channel. | |||
There was a problem hiding this comment.
TAGMSG too --- any others?
There was a problem hiding this comment.
idk, TAGMSG isn't mentioned elsewhere in the spec, and it seems obvious that TAGMSG should behave like PRIVMSG and NOTICE
There was a problem hiding this comment.
Sounds like we need a section covering TAGMSG :-)
There was a problem hiding this comment.
Is it a goal to import all IRCv3 specs into modern? I see some are mentioned but it's a bit random.
There was a problem hiding this comment.
Having two copies of the same documentation will inevitably go out of sync. I suggest to stick with referencing the (coherent & unambiguous) docs already on the ircv3 site.
There was a problem hiding this comment.
@jwheare my intention has usually been to update the base doc (e.g. syntax, formats, etc) wherever needed to explain the basics, then link off to v3 for the full story. E.g. in the Capability Negotiation section Modern gives an overview, but then says to refer to the actual spec for details:
There was a problem hiding this comment.
On which ones to mention, I've always thought about it like "optimistic real use", like whether Modern mentions something or not depends on whether it's used in the real world by software today, with a lean towards being optimistic about v3 stuff.
My thought was always while it'd be great to include docs on e.g. most of the unambiguous stuff from 'defs' that'd just be... so much work... so that's why I stuck to the core-feeling things for the base Modern doc.
There was a problem hiding this comment.
For PRIVMSG/NOTICE i'd stick with the documented 401 NOSUCHNICK, which commonly has the text "No such nick/channel". Note that 401 is already listed as a response to these commands in both rfcs (and consequently modern-irc as well), whereas 403 is not.
Both TOPIC and MODE already list 403 NOSUCHCHANNEL as a response on modern-irc.
So except for the suggestion, i'm ok.
|
I missed this earlier, but I would suggest mentioning |
|
done |
|
The text is confusing, are you suggesting ERR_NOSUCHCHANNEL and ERR_NOTONCHANNEL to be valid responses to PRIVMSG and NOTICE? |
|
that's not my intent, I need a better way to phrase this. |
This matches InspIRCd's behavior, which Ergo is considering too.
As far as I can tell, no one else implements it this way, so this is not phrased as a requirement.